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IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 

5 TITLE: Minimal Latency Serial Media Independent Interface to 

Media Independent Interface Converter 

SPECIFICATION 

10 

Authorization Pursuant to 37 CF.R. 1.71(e) 

A portion of the disclosure of the patent document contains material which is subject to 
copyright protection. The copyright owner has no objection to the facsimile reproduction by 
anyone of the patent document or the patent disclosure, as it appears in the Patent and 
15 Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever. 

Background 

1. Field of the Invention 

The present invention relates to networking a computer system, and more particularly to a 
converter that speeds up conversion of signals between a Serial Media Lidependent Interface 
2 0 (SMII) and a Media Independent Interface (ME) regardless of a reduction in the number of pins 
that are available. 

2, Description of the Related Art 

Many computer systems today are utilized in a network configuration where each 
network computer can transmit data to other computers on the same network. Various systems 
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and related protocols have been developed over the years to implement such networks, such as 
Ethernet, Token Ring, and ATM. Depending upon which network protocol is utilized, certain 
requirements must be met, such as the type of hardware used and particular data characteristics. 

The Ethernet network is a well-known communication network and is considered by 
5 many to be the most popular LAN system in use today. Since the beginning of the Ethernet 
protocol in the early 1970s, computer networking companies and engineering professionals 
have continually strove to improve Ethernet product versatility, reliability and transmission 
speeds. To ensure that new Ethernet products were compatible and reliable, the Institute of 
Electrical and Electronic Engineers (IEEE) formed a working group to define and promote 
10 industry LAN standards. Today, the IEEE has various Ethernet working groups that are 
responsible for standardizing the development of new Ethernet protocols and products under an 
internationally well-known LAN standard called the "IEEE 802.3 Standard", 

In general, the Ethernet network provides for connmunication of computer data amongst 
user nodes attached to the network. A 10-Base Ethernet system operates to transmit data 

15 packets from a source address to a destination address at a speed of 10 Mbps (megabits per 
second). A faster system is the 100-Base Ethernet system which similarly operates to transmit 
data packets from a source address to a destination address but at a speed of 100 Mbps. It 
should be noted, however, that the traditional Ethernet network is a bus type topology. As such, 
the Ethernet network has been traditionally confined to LAN apphcations. For example, the 

20 10/100-Base Ethernet bus is typically hmited to approximately 100 feet from node to node, 
such as for use in small buildings and the like. 
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Efforts to improve the networking of digital computers and the transmission of digital 
data have been the object of significant research and development in the past. Networking 
allows computers to share resources, access huge stores of information, communicate via e- 
mail, share data, and transfer files. Networking technology and digital data transmission have 
been subject to a number of bandwidth and speed limitations. 

In the past, networking technology has suffered from limitations on data transmission 
rates which limit the bandwidth of the system. For example, local area networks (LANs) may 
be connected with cables that have finite limitations on the amount of data they can pass, and 
the speed at which it can be done. LANs may be connected to extended wide area networks 
(WANs) over transmission lines that have bandwidth limitations. When modems are required 
for communication over conventional telephone lines, severe lintiitations may be imposed upon 
data transmission rates. 

Currently, there are a wide variety of standard Ethernet compliant products used for 
receiving, processing, and transmitting data over Ethernet networks. These products include, 
by way of example, network interface card (NICs), routers, switching hubs, bridges, and 
repeaters. Until recently, common data transmission speeds over Ethernet networks were 
10Mbps. However, to meet the demand for faster data transmission speeds, the IEEE 802.3 
Standards Committee officially introduced another standard - - the IEEE 802.3u Standard ~ for 
a 100BASE-T system capable of performing data transmission at up to 100Mbps. When 
operating with a UTP cable as a transmission medium, these networks are commonly referred 
to as lOBASE-T and 100BASE-T networks. 
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Network devices generally adhere to an open systems interconnection (OSI) layered 
model developed by the Memational Organization for Standards (ISO) for describing the 
exchange of information between layers. The OSI layered model is particularly useful for 
separating the technological functions of each layer, and thereby facilitating the modification or 
5 update of a given layer without detrimentally impacting the functions of neighboring layers. 

Multiple layers defined in the OSI model are responsible for various functions, 
including: providing reliable transmission of data over a network; routing data between nodes 
in a network; initiating, maintaining, and terminating a communication link between users 
connected to the nodes; performing data transfers within a particular level of service quality; 

10 controlling when users are able to transmit and receive data depending on whether the user is 
capable of full-duplex or half-duplex transmission; translating, converting, compressing, and 
decompressing data being transmitted across a medium; and providing users with suitable 
interfaces for accessing and connecting to a network. The lower portion of the OSI model 
includes a media access control (MAC) layer, which generally schedules and controls the access 

15 of data to a physical layer (PHY). 

At the lower most portion of the OSI model, the PHY layer is responsible for encoding 
and decoding data into signals that are transmitted across a particular medium, such as a cable. 
To enable transmission to a particular medium, the PHY layer also includes a physical 
connector which is configured and operable to receive the cable. In addition, the cable can take 
20 various forms, including that of an unshielded, twisted pair (UTP) cable, which is used for 
various types of Ethernet transmission, including lOBASE-T and 100BASE-T. 
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In order for a network to accommodate a number of users efficiently, routing and flow 
control procedures have to be established. There are many rules that must be followed, and 
these rules are typically referred to as protocols. Packet-switched networks subdivide digital 
data messages into packets. The digital data is then transmitted packet by packet. Each packet 
must contain not only the information bits comprising the digital data that is to be transmitted, 
but also information bits which are overhead required by the protocol in use, such as 
information bits which identify the destination of the packet, the source of the packet, and 
synchronization bits. Overhead bits typically appear in a header and trailer to each packet. In 
addition, acknowledgement packets must be transmitted over the network to confirm receipt of 
a packet of data. Alternatively, a protocol may include information in the overhead bits in each 
packet indicating the number of the packet. This information may be used to reassemble the 
received packets in the correct order, and if a packet is missing, a negative acknowledgement 
packet may be sent to request retransmission of the missing packet. Otherwise, data loss could 
occur and not be detected by the system. In any event, acknowledgement packets and other 
similar handshaking information which must be transmitted over the network according to the 
protocol impose some limitations upon the data throughput of the network. While this may be 
acceptable in many instances, in appUcations where the transfer of huge amounts of data are 
required, these bandwidth limitations may render such applications impractical in practice. 

It is not uncommon for two or more users on a network to attempt to transmit a packet 
at the same time. When this occurs, it is referred to as a collision. Neither packet will be 
received successfully, and both must be retransmitted. Obviously, this reduces the throughput 

6 

0052437.0029 AUSTIN 216296 vl 



LSI No. 00-065 



of the network. Different protocols employ various schemes to determine the timing of 
retransmission attempts in an effort to avoid repeated collisions between the same two users. 

Data transmission may sometimes experience data errors, where a digital "1" is 
erroneously received as a "0", or vice versa, due to such events as signal fluctuations or noise. 
Thus, error correction schemes may be employed in an effort to detect data errors. If an error is 
detected, then a packet must be retransmitted. Of course, when a packet must be retransmitted, 
it reduces the overall throughput of the network. 

Networking technology has suffered from limitations resulting from a proliferation of 
non-standard protocols, and limitations due to the nature of the protocols and transmission 
schemes which are employed. Additional overhead may be imposed when conversion from one 
protocol to another is required. This additional overhead may effectively limit the overall 
bandwidth of the network. 

Networks may need to be connected by hubs, routers, and other switches. A hub, for 

example, may have a number of ports, and each port may be connected to a network, such as a 

LAN or a wide area network. When a packet is received at a hub, the hub switch must 

determine to which port the packet is to be switched. Alternatively, the packet may be switched 

to all ports and broadcast over every network connected to the hub. However, if every hub 

broadcasts every packet on every port, the amount of traffic on the network will be increased 

and the throughput will invariably suffer. Under heavy traffic, any attempt to determine to 

which port a packet must be switched must be accomplished speedily to avoid slowing 

throughput of the network. Therefore, it is desirable to have a method for determining over 
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which port a packet should be transmitted. 

In addition to limitations on bandwidth, all of the above discussed factors may affect 
cost, response time, throughput, delay, maximum transmission rates, and reliability. Many other 
problems and disadvantages of the prior art will become apparent to one skilled in the art after 
comparing such prior art with the present invention as described herein. 
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Summary of the Invention 

Various aspects of the present invention may be realized through a method for reducing 
latency in conversions from a SMH (Serial Media Independent Interface) to a ME (Media 
Independent Interface). The method involves generating receive and transmit clock signals 
from a physical layer device; generating receive and transmit clock signals at a media access 
controller; and synchronizing the clock signals at the media access controller and the clock 
signals at the physical layer device such that Mil clocks are generated from the SMH and a 
synchronization signal of the SMH is always delayed 8 nsec from a positive edge of the Mil 
clock. 

In some embodiments, the SME is configured to receive digital information at the same 
time that the Mil receives other digital information. The digital information is commonly a 
nibble. Of note, the digital information is commonly exchanged during a second part of a frame 
of the ME. 

Other aspects of the present invention are realized in a SME to ME converter that 
includes an SME that sends and receives frames that are configured to transmit data in an SME 
standard format and an MB that sends and receives frames that are configured to transmit data 
in an ME standard format. An ME frame has a first part and a second part where a first nibble 
is driven to the SME at the second part of an ME frame. A second nibble is received on the 
ME frame at the same time the first nibble is being driven to the SME. The ME has clocks that 
are generated from the SME clock and synchronized such that latencies are reduced between 
conversions from SME to ME. 

9 

0052437 0029 AUSTIN 216296 vl 



LSI Na 00-065 



In one embodiment, the synchronization signal of the SMII to MEL converter is always 
delayed 8 nsec from a positive edge of the ME clock. 

Still other aspects of the present invention are realized through a method for using 
standard FIFO (First in First Out) techniques and a parallel to serial converter to convert nibble 
5 wide data to bit wide data in a data stream. The method involves, not necessarily in this order, 
transmitting SME frames such that frames are sent and received that are configured in an SMII 
standard format; transmitting ME frames such that frames are sent and received that are 
configured in an ME standard format, the ME frames each having a first part and a second part; 
driving a first nibble to the SME at the second part of an ME frame; receiving a second nibble 
10 on the ME at the same time the first nibble is being driven to the SME; generating ME clocks 
from an SME clock; and synchronizing the ME clock and the SME clock such that latencies are 
reduced between conversions from SME to ME. 

It should be noted that synchronizing the ME clock and the SME clock may involve 
consistently delaying a synchronization signal by 8 nsec from a positive edge of the ME clock. 

15 Various aspects of the present invention may also be found in a method for using 

standard FIFO techniques and a parallel to serial converter to convert nibble wide data to bit 
wide data in a data stream. The method includes synchronizing clock signals of a ME in a 
media access controller and other clock signals of a SME to consistently delay a 
synchronization signal by 8 nsec from a positive edge of the ME clock. 
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Bmef Description of the Drawings 

A better understanding of the present invention can be obtained when the following 
detailed description of the drawings is considered in conjunction with the following drawings. 

Fig. 1 is a block diagram of an exemplary media access controller (MAC) shown 
interacting with a network through an SMH to MH converter according to principles of the 
present invention. 

Fig. 2 is an exemplary timing diagram that demonstrates relationships between SMH 
and MH signals using the device of Fig. 1. 

Figs. 3-5 illustrate state diagrams showing operation of an SMH transmit data path 
according to principles of the present invention. Fig. 3 illustrates a TXSampler stage. 

Fig. 4 illustrates a TXOutGenerator stage. 

Fig. 5 illustrates a TXFrameGenerator stage. 

Figs. 6-8 illustrate state diagrams showing operation of an SMH receive data path 
according to principles of the present invention. Fig. 6 illustrates a receive frame assembler. 

Fig. 7 illustrates a receive output generator. 

Fig. 8 illustrates a receive MR driver. 



0052437 0029 AUSTIN 216296 vl 



11 



LSI No. 00-065 

Detailed Description of the Drawings 

Networks that include a PHY layer, such as an Ethernet network, are typically defined to 
include a Media Independent Interface (MH) that requires 16 pins to carry out data 
transmission. However, complete ME information may be conveyed between a 10/100 PHY 
5 and a MAC using only 2 pins per port when a Serial Media Independent Interface (SMII) is 
used. The SMR specification was originally developed by Cisco Systems. Use of an SME 
interface not only lowers pin count per port, but may also simplify board layout and design. 
The SME reduces pin counts per port from 16 to just 2 pins, thereby reducing the packaging 
costs for both MAC ASICs and transceivers. Pin reduction is accomplished when the devices 
10 operate according to the SME specification. The SME specification involves operating with 
one system clock and in both half and full duplex modes. However, the SME specification 
introduces latencies in the datapath from the MAC to the wire, especially when the SME is a 
bolt-on over an existing ME based MAC or PHY. 

The SME specification reduces the number of pins between a switch/MAC ASIC and a 
15 physical layer device. More particularly, transmitted information is communicated with one pin 
while receive information is communicated with another pin. However, the SME specification 
introduces latencies in the data path from the MAC to the transmission media, especially when 
the SME is a "bolt-on" over an existing ME-based MAC or PHY. In such instances, the SME 
functionahty may cause a design to exceed the IEEE-specified signal transmission latency 
2 0 limits. 



0052437.0029 AUSTIN 216296 vl 



12 



LSI No, 00-065 



In a typical implementation, the Mil receive clock RXCLK and transmit clock TXCLK 
are provided to the MAC from the PHY. Accordingly, an SMII to Mil converter according to 
the present invention generates these clocks. 

Fig. 1 is a block diagram of an exemplary media access controller (MAC) 100 shown 
interacting with a network 102 through an SMII to ME converter 104 according to principles of 
the present invention. Signal transmission between the MAC 100 and a PHY 106 as SMII_TX 
(transmit), SMn_RX (receive), SMH^SYNC (synchronization), and SMH^CLK (clock) are 
illustrated to demonstrate the interactions of the devices of a converter that operates according 
to principles of the present invention. 

The converter reduces latencies because it is synchronized to the SMII_S YNC signal so 
that the clock allows the first nibble to be driven on to the SMII at the second part of the same 
Mn frame in which the second nibble is getting received on the Mil. This ensures that the data 
is transmitted out with the first available sync. ME clocks are generated from the SMII clock 
and latencies are reduced to 1 to 5 bit times as compared with classical latencies of 8 to 16 bit 
times. The SMH^SYNC is always delayed by 8 nsec from the positive edge of the MR clock. 
The SMn frames start at the first available SYNC after an ME transmit signal is asserted. 

Fig. 2 is an exemplary timing diagram that demonstrates relationships between SME 

and ME signals using a device similar to the device of Fig. 1. The ME RXCLK and TXCLK 

are generated from the PHY and given to the media access controller (MAC). During the start 

of a transmit frame, the first nibble can be driven on the SME in the following SME frame. In 

this case, the latency is only one SME frame. However, when the ME TX_EN is found asserted 

13 
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during cycle 8 of an SMH frame and during the start of a transmit frame, the first nibble is sent 
on the SMH during the following SME frame only. This is due to the requirement of MH 
TX_ER bit in the SMH frame. In this case, the latency is about 1.5 SMH frames. 

The receive datapath needs to store information for one byte duration so that 
information is available from the first status frame following the data frames while still holding 
the last nibble to be received on the MR. Prior to transmission of the last nibble on ME, 
appropriate action may be taken if certain information is detected. These operations may be 
performed in either lOOBaseX mode or lOBaseX mode. However, lOBaseX mode is different 
because the transmit on SMH starts after sampling two nibbles on MH, since the MH txclk runs 
at 2.5MHz. In addition, in the receive SMK frame, sampling is carried out at the last of the 
repeated frames, i.e., every SME frame is repeated ten times to cope with the reduced data rate. 
This is done so that the last byte of the packet on MH may be sent and sampled to take 
appropriate action. 

These procedures result in the fastest MH to SMH conversion module that can be used 
with existing MACs and still meet overall bit budgets. This amounts to one synchronization 
every two MH clock cycles when a sync occurs every ten clocks at a 125MHz rate. 

Appendix A includes sample code of an embodiment according to principles of the 
present invention of the SMU to MH conversions. A converter may also find use in Reduced 
Media Independent Interface (RMII) products. The clock divider circuitry of the SMH to MH 
converter is synchronized to the SME synchronization signal (SYNC) in order to reduce 
transmit signal latencies. 

14 
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Figs. 3-5 illustrate state diagrams showing operation of an SME transmit data path 
according to principles of the present invention. Fig. 3 illustrates a first stage of logic sample 
that the ME transmit signals on every clock cycle in which the positive edge of the ME TXCLK 
is generated. This sampling stage can store the data for two ME clock cycles, i.e., one byte of 
data. This first stage is sometimes referred to as the TXSampler stage. 

Fig. 4 illustrates second stage logic which is enabled only during clock cycle 7 of the 
SME frame. This allows for preparation of the SME Transmit frame data that is going to be 
sent out in the following SME TX Frame. Depending on how the ME tx„en is asserted, this 
second stage sends the byte already sampled by the first stage or the nibble sampled by the first 
stage in the earlier ME clock, along with the nibble currently getting sampled in ME in this 
cycle to the following SME TX Frame. This stage is often referred to as the TXOutGenerator 
stage. 

Fig. 5 illustrates a third stage that simply sends out respective bits from the output of the 
second stage (Fig. 4) on SME at the respective bit times. This stage is often referred to as the 
TXFrameGenerator stage. 

Figs. 6-8 illustrate state diagrams showing operation of an SME receive data path 

according to principles of the present invention. Fig. 6 illustrate the first stage where bits are 

assembled into frames. This stage is known as the receive frame assembler. The bits have been 

received on the SME and in lOOBaseX mode, the assembled frame is transferred to a second 

stage. In lOBaseX mode, the received frames are repeated 10 times to cope with the rate 

reduction by 10. Since at least one status frame must be sampled before sending out the last 

15 
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byte of a received packet to MH, a modulo 10 counter is run counting the number of frames 
when RX_DV is asserted. The contents of the receive frame assembler is transferred at the end 
of every 10th frame to temporary registers prior to being transferred to the second stage. 

Fig. 7 illustrates the second stage and is commonly referred to as the receive output 
generator. As mentioned above, the second stage may receive bits from either a lOOBaseX or a 
lOBaseX system. The information is passed to a third stage when ready. 

Fig. 8 illustrates the third stage which is referred to as a receive MH driver. This stage 
generates the MH receive outputs from the output of the receive output generator of Fig. 7. In 
lOOBaseX mode, MH outputs are generated at cycle 4 and 9 of the SMH frame so that they may 
be sampled on the positive edge. In lOBaseX mode, the positive edge occurs once in every 5 
SMH frames. 

The above-listed sections and included information are not exhaustive and are only 
exemplary for network systems having a PHY with an MD in the corresponding MAC. The 
particular sections and included information in a particular embodiment may depend upon the 
particular implementation and the included devices and resources. Although a system and 
method according to the present invention has been described in connection with the preferred 
embodiment, it is not intended to be hmited to the specific form set forth herein, but on the 
contrary, it is intended to cover such alternatives, modifications, and equivalents, as can be 
reasonably included within the spirit and scope of the invention as defined by the appended 
claims. 
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Code: 

//************************************************************ 
//* * 
//* * 

//* This file may not be reproduced, modified, disclosed or * 
//* otherwise used without express written permission of * 
//* an authorized officer of LSI Logic Corporation. * 
//* * 

//* Networking Products Division, LSI Logic Corporation 1999.* 
//* * 

************************************* ************* 

// 

// FILENAME : mac_smii.v 
// 

// DESCRIPTION : MAC side SMII to Mil converter 
// 

// PROJECT : PHY 110 / Infinity L64324 

// 

// LSI Logic Corp 

// Copyright (c) 1995-2000, LSI Logic Corp. 
// All Rights Reserved 

// 

// This module is the MAC side SMII to Mil converter module 
// which converts the SMII interface provided by a PHY 
//to Mil interface on the MAC 

// 

"timescale Ins/lOps 
module mac_smii ( 

// 

// Outputs. 

// 

// 

// SMII 

// 

smii_txd, // SMII Transmit Data 

// 

// Mil 

// 

mcol, // Mil Collision 
mcrs, // Mil Carrier Sense 
mrxdv, // Mil Receive Data valid 
mrxer, // Mil Receive Error 
mtKC, // Mil Transmit Clock 
mrxc, // Mil Receive Clock 
mrxd, // Mil Receive Data Nibble 

// 

// SMII Status 

// 

speed, // Speed Status from SMII 
duplex, // Duplex Status from SMII 
link, // Link Status from SMII 
jabber_smii, // Jabber Status from SMII 

// 

// Miscellaneous 
// 

activity, // Activity output for LED 

// 

/ / Inputs . 

// 

// 

// SMII 

// 

smii_rxd, // SMII Receive Data 
sync, // SMII SYNC 

// 

// Mil 

// 

mtxen, // Mil Transmit Enable 
mtxer, // Mil Transmit Error 
mtxd, // Mil Transmit Data Nibble 

// 

// Resets and Clocks 
// 

clkl25, // 125MHz SMII Reference Clock 
resetn // Main Reset ( Active Low ). 

); 

parameter tQ = 1; . 
output smii_txd; 
output mtxc; 
output mrxc; 
output mrxdv; 
output [3:0] mrxd; 
output mrxer; 

17 
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output mcol; 

output mcrs; 

output speed; 

output duplex; 
5 output link; 

output jabber__smii; 

output activity; 

input siiiii_rxd; 

input sync; 
10 input mtxer; 

input mtxen; 

input [3:0] mtxd; 

input clkl25; 

input resetn; 
15 reg smii^txd; 

reg smii_pre_txd; 

reg sniii_Dre_rxd; 

reg sync_pre; 

reg [2:03 clk25_cnt; 
20 reg [3:0] clkl2_5_cnt; 

reg clkl_25; 

reg miiclk; 

reg txen_samp_0; 

reg txen_samp_l; 

2 5 reg txer_samp_0 ; 

reg txer_sanip_l; 
reg [3:0] txd_saiap_0 ; 
reg [3:0] txd_samp_l ; 
reg txer_out; 
30 reg txen_out; 

reg [7:0] t xd_by t e_ou t ; 
reg tx_phase; 
wire clkl2_5; 
wire mtxc; 

3 5 wire mrxc; 

reg [9:0] rx_f rame_data; 

reg rxdv_out; 

reg [7:0] rxd_out; 

reg rxdvlO_store; 
40 reg [7:0] rxdlO_3tore; 

reg [3:0] rxlO_f rainG_cnt; 

reg rxer_store; 

reg up_nib_val_store; 

reg speed; 
45 reg duplex; 

reg link; 

reg jabber; 

reg mrxdv; 

reg mrxer; 
50 reg [3:0] mrxd; 

wire mcol; 

wire mcrs; 

wire jabb6r_smii; 



55 // Clocks Generation Start. 

// 

assign mtxc = miiclk; 

assign mrxc - miiclk; 

// synopsys async_set_reset "resetn" 
60 always & ( posedge clkl25 or negedge resetn ) 

begin 

if C resetn == I'bO ) 
begin 

sync_pre <= #(tQ) I'bO; 
65 end 

else, 
begin 

sync_pre <= #(tQ) sync; 
end 

70 end 

always @ ( posedge clkl25 or negedge resetn ) 
begin 

if ( resetn == I'bO ) 
begin 

75 clk25_cnt <= #(tQ) 3'hO; 

cXkl_25 <= #(tQ> I'bO; 

miiclk <= #(tQ) I'bO; 

end 

else 
8 0 begin 

if ( speed ) 

begin 

// 

clkl 25 #(tQ) I'bO; 

85 // 

miiclk <= #{tQ) '-(clk25_cnt[2] | clk25_cnt [1] ) 
// 

if ( ( sync_jpre ^= I'bl ) || 
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C clk25_cnt[2] I'bl ) ) 
clk25_cnt #(tQ) 3»h0; 

clk25_cnt <= #(tQ) clk25_cnt + I'bl; 
end 

else if ( clkl2_5 == I'bl ) 

begin 

// 

miiclk <= #(tQ) - (clk25_cnt [2] | clk25_cnt [1] ) ; 
// 

if ( clk25_cnt[2] == X'bl ) 
begin 

clkl_25 #(tQ) -clkl_25; 

clk25_cnt <= #{tQ) 3'hO; 

end 

else 

begin 

Clfc25_cnt <= #(tQ) clfc25_cnt + I'bl; 

end 

end 

end 

end 

assign clkl2_5 = ( clkl2_5_cnt [2 : 0] == 3'h6 ); 
always & ( po sedge clkl25 or negedge resetn ) 
begin 

if ( resetn == I'bO ) 
begin 

clkl2_5_cnt <= #CtQ) 4'hO; 

end 

else 

begin 

if { sync_pre == I'bl ) 
clkl2_5_cnt <~ #(tQ) 4 "hi; 
else if ( clkl2_5_cnt 4'h9 ) 
clkl2_5_cnt <= #{tQ) 4'hOj 
else 

clkl2_5_cnt <= #(tQ) clkl2_5_cnt + I'bl; 

end 

end 

// 

// Clocks Generation End» 

// 

// 

// SMI I Transmit Start. 

// 

// 

// Following samples the Mil TX data. (Tx_SainEpler) 



always & ( posedge clkl25 or negedge resetn ) 
begin 

if { resetn == I'bO ) 
begin 

txen_samp_0 <= #(tQ) I'bO;. 
txen__samp_l <= #(tQ) I'bO; 
txer_samp_0 <= #(tQ) I'bO; 
txer__samp_l <= #(tQ) I'bO; 
txd_sainp_0 <= #{tQ) 4'bO; 
txd_samp_l <= #(tQ) 4'hO; 
end 
else 
begin 

if ( ( speed == I'bl ) j | 
{ ( speed == I'bO ) &fc 
( clkl2_5 == I'bl ) ) ) 
begin 

if ( «|clk25_cnt ) 
begin 

{txen_sajnp_l, txen_samp_0} <= #(tQ) {txen_sainp_0, mtxen}; 

{txer_sainp_l, txer_samp_0} <= #(tQ) {txer_sainp_0, (mtxer & speed)}; 

{txd_sainp_l, txd_samp„0} <= #(tQ) {txd_samp_0, ({4{mtxen}} & mtxd) } 

end 

end 

end 

end 

// 

// Following generates the TX output data 

// from the Mil sampled TX data. (Tx_Out Generator) 

// 

always Q- ( posedge clkl25 or negedge resetn ) 
begin 

if ( resetn I'bO ) 
begin 

txer_out <= #{tQ) I'bO; 
txen_out <= #(tQ) I'bO; 
txd_byte_out #(tQ) 8'hO; 
tx_phase <= #{tQ) I'bO; 
end 
else 
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begin 

if ( ( clkl2_5 == I'bl ) && 

( ( clk25_cnt[l] == I'bO ) && { clk25_cnt [0] == I'bO ) ) && 
( ( speed =^ I'bl ) I | 

( C speed I'bO ) && ( clkl_25 == I'bO ) && ( clk25_cnt[2] == I'bO ) ) ) ) 
begin 

// 

if ( txen_out == I'bO ) 
begin 

if ( { txen_sajnp_l == I'bl ) && 
( txen__sainp_0 =« I'bl ) ) 
begin 

tx_j>has6 <= #(tQ) I'bl; 

end 

else 

begin 

tx_phase #(tQ) I'bO; 

end 

end 

// 

if ( tx6n_out =- I'bO ) 
begin 

if ( { txen„sainp_l == I'bl ) && 
( txen_samp_0 == I'bl ) ) 
begin 

txer_out <= #{tQ) (txer_samp_l | txer_saitip_0 ) ; 
txen_out <= #(tQ) I'bl; 

txd„byte_out <= #(tQ) {txd_samp_D, txd_sain.p_l} ; 
end 

else if ( txen_sainp_0 == I'bl ) 
begin 

txer_out <- #(tQ) ( txer_3amp_0 ] (mtxen & mtxer & speed) ); 
txen_out <= #(tQ) I'bl; 

txd_byte_out <= #(tQ) {mtxd, txd_samp_0}; 

end 

else 

begin 

txer_out <= #(tQ) I'bO; 

txen_out <= #(tQ) I'bO; 

txd_byte_out <= #(tQ) 8*h0; 

end 

end 

else 

begin 

if ( tx_phase == I'bl ). 
begin 

txer_out <= #(tQ) ( tx6n_saii)p_l & 
(txer_samp_l | txer_sa2np_0) ); 
txen_out <- #(tQ) txen_samp_l ; 

txd_byte_out <= #(tQ) ({8{txen_saiap_l}} & {txd_sainp_0, txd_3ainp_l}) ; 

end 

else 

begin 

txer_out <- #(tQ) ( txen_sainp_0 & 

{ txer_samp_0 | (mtxen & mtxer & speed) ) ) ; 

txen_out <= #(tQ) txen_samp_0; 

txd_byte_out <= #(tQ) ( { 8 { txen_samp_0 } } & {({4 {mtxen}} & mtxd) , txd_samp_0} J 

end 

end 

// 

end 
end 
end 

// 

// Following creates the SMII TX Frame by 

// sequencing the respective bits,(Tx Frame Generator) 



always @ ( posedge clkl25 or negedge resetn ) 
begin 

if ( resetn == I'bO ) 
begin 

smii_pre_txd <= #(tQ) I'bO; 

end 

else 

begin 

case ( clkl2_5_cnt ) 
4'h7: // TxER sent here 
begin 

smii_pre_txd <= #(tQ) txer_out; 
end 

4'h8: // TxEN sent here 
begin 

smii_pre_txd <= #{tQ) txen_out; 
end 

4'h9: // TxDO sent here 
begin 

smii_pre_txd <= #(tQ) txd__byte_out 1 0 3 ; 
end 
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4'hO: // TKDl sent here 
begin 

sitii i_pre_txd <= # { tQ) txd_byt e_out [ 1 ] ; 
end 

4 'hi: // TxD2 sent here 
begin 

smii_pre_txd <= #(tQ) txd_byte_out [2] ; 
end 

4»h2: // TkD3 sent here 
begin 

smii_pre_txd <= #(tQ) txd_byte_out [3] ; 
end 

4»h3: // TxD4 sent here 
begin 

sinii_j)re_txd <= #(tQ) txd_byte_out [4] ; 
end 

4'h4: // TxD5 sent here 
begin 

smii_pre_txd <= #(tQ) txd_by te_out E 5 ] j 
end 

4'h5: // TxD6 sent here 
begin 

smii_pre_txd <= #(tQ) txd„byte_out [6] ; 
end 

4'h6: // TxD7 sent here 
begin 

smii^re^txd <= #(tQ) txd_by t6„out [ 7 ] ; 
end 

default : 
begin 

siaii_pre_txd <= #(tQ) I'bO; 
end 

endcase 

end 

end 



// Following is the delivery flip-flop for 
// SMII TX. 

// 

always & ( posedge clkl25 or negedge resetn ) 
begin 

if C resetn == I'bO ) 
begin 

smii_txd <= #(tQ) I'bO; 

end 

else 

begin 

smii_txd <= #(tQ) smii_pre_txd; 

end 

end 

// - 

// SMII Transmit End, 

// 

// 

// SMII Receive Start, 

// 

// 7 

// First stage receive flip-flop Registers 
// SMII RX directly. 



always & { posedge clkl25 or negedge resetn ) 
begin 

if ( resetn == l*bO ) 
begin 

smii_pre_rxd <= #{tQ) I'bO; 

end 

else 

begin 

smii_pre_rxd <= #(tQ) smii_rxd; 

end 

end 



// Following registers the RX frame 

// depending on the bit in the frame (Rx Frame Assembler) 



always @ ( posedge clkl25 or negedge resetn ) 
begin 

if ( resetn == I'bO ) 
begin 

rx_frama_data <= #(tQ) 10 'hO; 

end 

else 

begin 

case { clkl2_5_cnt ) 

4'hO: // CRS received here 

begin 

rx_frame_data[03 <= #(tQ) smii_pre_rxd; 
end 
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4 'hi: // RX_DV received here 
begin 

rx_frame_data[13 <= #(tQ) 3niii_pre_rxd; 
end 

4'h2t // RkDO/RX_ER received here 
begin 

rx_frain©_data[23 <= #(tQ) smii _pre_rxd; 
end 

4'h3: // R3tDl /Speed received here 
begin 

rx_fraine_data[3] <= #(tQ) smii_pre_rxd; 
end 

4'h4: // RxD2 /Duplex received here 
begin 

rx_frame_data[4] <= #(tQ) smii_j)re_rxd; 
end 

4'h5: // RxDS/Iiinfc received here 
begin 

rx_fram6_data[53 <= #{tQ) smii_pre_rxd; 
end 

4'h6: // RxD4 /Jabber received here 
begin 

rx_frame_data[6] <= #{tQ) 3niii_pre_rxd; 
end 

4'h7i // RxD5/Upp_nib_val received here, 
begin 

rx_fraiiie_data[7] <= #(tQ) smii_pre_rxd; 
end 

4'h8: // RxD6/Fls_car received here 
begin 

rx_fram&_data [8] <= #(tQ) sinii_pre_rxd; 
end 

4'h9: // 3txD7 received here 
begin 

rx_frame_data[9] <= #(tQ) smii_pre_rxd; 
end 

default: 
begin 

rx_fraitiQ_data <= #(tQ) 10 'hO; 
end 

endcase 

end 

end 

// 

// Following counts lOBaseX Frames when rxdv 
// is asserted. (Rx Frame counter for lOBaseX) 
// 

always & { posedge clkl25 or negedge resetn ) 
begin 

if ( resetn == I'bO ) 
begin 

rxlO_frame_cnt <= #(tQ) 4'hO; 

end 

else 

begin 

// 

if ( speed I'bO ) 
begin 

if ( clkl2_5_cnt == 4'hO ) 
begin 

if { { rx_£raine_datall] == I'bl ) J| 

( rxdvlO_store == I'bl ) ) 

begin 

if ( rxlO_frame_cnt == 4'h9 ) 
rxlO_frame_cnt <= #(tQ) 4'hO; 
else 

rxlO_frame_cnt <= #(tQ} rxlO_f rame_cnt + I'bl; 

end 

else 

begin 

rxlO_frame_cnt <= #(tQ) 4'hO; 

end 

end 

end 

else 

begin 

rxlO_frame_cnt <:= #(tQ) 4'hO; 

end 

// 

end 

end 

// 

// Following stores the rxdv and rxd[7;0] 
// in lOBaseX mode when the frame count 

// is 9 ( last of the 10 repeated frames ) . ( Rx Temp store for lOBasex ) 
// 

always @ { posedge clkl25 or negedge resetn ) 
begin 
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if { resetn -= I'bO ) 
begin 

rxdvlO_storG <= #(tQ) I'bO; 
rxdlO_store <= #CtQ) 8'hO; 
5 end 
else 
begin 
// 

if ( { speed == I'bO ) && ( rxlO_frai[ie_cnt === 4'h9 ) && ( clkl2_5_cnt == 4'li0 ) ) 
1 0 begin 

rxdvl Orator© <= #(tQ) rx_f rame_data [1] ; 
rxdlO_store <= #{tQ) rx_f raine_data[9 : 2] ; 
end 

15 end 
end. 

// — 

// Following generates the rxdv_out and 
// rxd_out[7:0] synchronous to the generated 
2 0 // Mil RX clock. (Rx Output Generator) 

// 

always & ( posedge clkl25 or negedge resetn ) 
begin 

if { resetn == I'bO ) 

2 5 begin 

rxdv_out <= #(tQ) I'bO; 
rxd_out <= #(tQ) 8'hO/ 
end 
else 

3 0 begin 

// 

if ( clkl2_5_cnt == 4'hO ) 
begin 

if ( speed =>= I'bl ) 

3 5 begin 

rxdv_out <= #(tQ) rx_frame_data[l] ; 
rxd_out <= #(tQ) rx_frame_dataC9;2],- 
end 

else if { {clkl„25,clk25_cnt} == 4'hO ) 

4 0 begin 

rxdv_out <= #(tQ) rxdvlO_store; 
rxd__out <= #(tQ) rxdlO_store; 
end 
end 
45 // 
end 
end 

// 

// Following registers the status bits from 
50 // the SMII Rx frame. ( Rx Status Register } 

// 

always & ( posedge clkl25 or negedge resetn ) 
begin 

if ( resetn == I'bO ) 

5 5 begin 

speed <== #(tQ) I'bOf 
duplex #(tQ) I'bO; 
link <= #(tQ) I'bO; 
jabber <= #(tQ) I'bO; 
60 rxGr_store <= #(tQ) I'bO; 

up_nib_val_store <= #(tQ} I'bl; 

end 

else 

begin 

65 // 

if ( clkl2_S_cnt == 4'hO ) 

begin 

// 

if ( rx_frame_data[l] -= I'bO ) 
7 0 begin 

speed <= #(tQ) rx_f rame_data [ 3 ] ; 

duplex <= #(tQ) rx__frame_data[4] ; 

link <= #{tQ) rx_frame_data[5] J 

jabber <= #(tQ> rx_fra2ne_data 163 ; 
75 end 

// 

if ( rx_frame_data[l] == I'bO } 
begin 

if ( ( speed I'bl ) II 
80 ( ( speed == I'bO ) && { Cclkl_25zClk25_cnt} ^= 4'hO ) ) ) 
begin 

rxer_store #(tQ) rx_f raine__data [2] ; 
up_nib_val _s t ore <= # ( t Q ) rx_f rame_da t a [ 7 ] ; 
end 

85 end 
else 
begin 

rxer_3tore <= #(tQ) I'bO; 
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up_nib_val_store <= #(tQ) I'bl; 

end 

end 

// 

5 end 
end. 

// 

// Following generates the Mil mrxdv mrxer 
// and mrxd. ( Rx Mil driver ) 

10 // ^ 

always & ( posedge clkl25 or negedge resetn ) 
begin 

if ( resetn == I'bO ) 
begin 

15 mrxdv <= #(tQ) I'bO; 

mrxer <= #(tQ) I'bO; 
mrxd <= #(tQ) 4»h0; 
end 
else 

2 0 begin 

if ( speed == I'bl ) // lOOBaseX 
begin 

if ( clkl2_5_cnt == 4'h3 ) // Lower Nibble phase 
begin 

25 mrxdv <= #(tQ) rxdv_out; ^ „ „ 

mrxer <= #(tQ) (rxdv_out) ? ( '-rx_frame_data[l] & rx_f rame_data [2] ) : // Rx Error. 
rxd_out[6]; // False Carrier. 

mrxd <= #CtQ) Crxdv_out) ? rxd_outC3:0] : (rxd_out[6]) ? 4'he : 4'hO; 
end 

3 0 else if ( clkl2_5_cnt 4'h8 ) // Upper Nibble phase 

begin 

if ( mrxdv == I'bO ) 
begin 

mrxdv <- #(tQ) I'bO; 
35 mrxer <= #(tQ) ( -rxdv.out & rxd_out[6] ); // False Carrier, 
mrxd <^ #CtQ) (rxd_out[6]) ? 4 'he : 4'hO; 
end 
else 
begin 

40 mrxdv <= #(tQ) rx_f rame_dataEl] 1 // Frame continues.. 

( -rx_frame_data[l] & rx_frame_data [7] ); //Or Upper Nibble Valid. 

mrxer <= #(tQ) ( '-rx_frame_data[l] & // Frame End and 

rx_f rame_data [7 ] & // Upper nibble valid and 

rx_frame_data[2] ); // Rx Error. 
45 mrxd <= #(tQ) rxd_out C7 : 4] ; 

end 

end 

end 

else // lOBaseX 

5 0 begin 

if { ( clkl2„5_cnt =- 4»h8 ) && 

( {clkl_25,clk25_cnt} == 4'h2 ) ) // Lower Nibble phase 
begin 

mrxdv <= #(tQ) rxdv_out; 
55 mrxer #(tQ) (rxdv_out) ? rxer_store : I'bO; 

mrxd <= #(tQ) (rxdv_out) ? rxd_out[3:0] : 4'hO; 
end 

else if ( ( clkl2_5_cnt === 4'h8 ) && 

{ {clkl_25,clk25_cnt} -= 4 'ha ) ) // Upper Nibble phase 

6 0 begin 

if { mrxdv === I'bO ) 
begin 

mrxdv <= #(tQ) I'bO; 
mrxer <= #(tQ) I'bO; 
65 mrxd #(tQ) 4'hO; 
end 
else 
begin 

mrxdv <= #(tQ) up_nib_val_store; 

7 0 mrxer <= #{tQ) up_nib_val_store & rxer_store; 

mrxd <^ #{tQ) rxd_out [7 : 4] ; 

end 

end 

end 

7 5 end 

end 1 . 

assign mcol = (duplex) ? I'bO : (rx_f rame_data [0] & mtxen) \ Dabb6r_smii; 

assign mors = (duplex) ? rx_f rame_data[0] : (rx_f rame^data [0] | txen„samp_l j txen_samp_0) ; 
assign jabber_smii = jabber; 

8 0 assign activity = {mtxen ] mrxdv) ; 

endmodule 
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